7 ms·

The more I read, the more I felt that the author was long-windedly discovering FSM's, only describing them using the language de-jour - i.e. JavaScript-ecosyste

• keyle 9y ago
  It's true that today's devs are glorified plumbers. On the other hand, so much gets done, it would be insane to go back to "C for all the things!". It's a trade off, you're either a high level hacker, piping stuff together and watching for leaks, or your a low level system guy, squeezing the carpet.
  • nigifabio 9y ago
    I will state the opposite: It's a trade off, you're either cut and paste blue collar programmer, piping stuff together and watching for leaks, or your a hacker/engineer guy, doing CS.
  • mmjaa 9y ago
    I would argue that a lot more of the worlds productive plumbing depends on C-based apps/libraries/frameworks than we would care to admit - its just that its 'not sexy' enough for the young-uns to get behind and start using, since everyone knows that C is a greybeard language and, therefore, not cool. The same argument ("so much gets done") was made for Visual Basic back in the day, you know. Oh, how the hoipolloi cried and crowed for the death of C developers back then. Oh, how they were wrong, oh so wrong! I'm not saying the world doesn't have a debt to pay to the Node/Javascript camp - it surely does. I just feel that there is something really missing in the scene, if in fact things that C developers knew and applied well 'back in the day' are just now being re-discovered as "Cool New Shit™" by those who chose - willingly - to ignore the very mechanics of the components their stacks are highly dependent on. Still, I guess its not worth complaining. Its good to know that JS guys can get over the wall, and discover that we've all been using state machines for decades now, and so on, eventually. I just wish there was a lot less hubris on the "crowing about it" side of things. Honestly, JS guys: you should know a little C. Its still there, underneath all the cool shit, and you're still heavily, heavily dependent on it, no matter what your "npm up" tells you...
    • coldtea 9y ago
      >The same argument ("so much gets done") was made for Visual Basic back in the day, you know. And it was right, to the argument is moot. VB was a very productive language. Any issues where with the ecosystem moving on, not with VB (which had its warts, but all languages do, C first of all). >Oh, how the hoipolloi cried and crowed for the death of C developers back then. Oh, how they were wrong, oh so wrong! Again, they were right, oh so right. We do 1000x the programming we did in 1980 and 1990, but we don't use 1000x more C programmers (or assembly or pascal, two other popular choices at the time). Tons of code that used to be that, is now written in higher level languages.
    • pjmlp 9y ago
      > Oh, how the hoipolloi cried and crowed for the death of C developers back then. Oh, how they were wrong, oh so wrong! Which is kind of true for us on Windows. Most of the C has been replaced by C++, to the point that even the new C runtime library is actually written in C++ with extern "C" entry points. Also for those of us on Android, where using the NDK is an exercise in patience writing JNI boilerplate, because Google doesn't want us using it more than strictly necessary. Oh and the two most beloved open source C compilers (gcc and clang) are actually written in C++. Now I admit that on traditional UNIX systems and embedded development on hardware constrained systems, getting rid of C is an impossible task.
    • Tade0 9y ago
      > since everyone knows that C is a greybeard language and, therefore, not cool. As a person who works as a front-end developer but after hours writes almost exclusively in Rust I think I could shed some light on what's going on here: Since JS is so accessible a lot of the folks who work with it don't even have a formal education in Computer Science(like the author, who's a CS student), so many of them never touched a compiled language in their life, not to mention subjects regarding CS. To these people most of the concepts in C(like manual memory management) are entirely foreign. It's not that they don't _like_ C, it's that they're utterly unaware of the mindset one has to have to write things in it. EDIT: grammar.
    • tcfunk 9y ago
      In my purely anecdotal experience, learning web-based technology over C/C++ was not a choice I made personally. It was a career path that was foisted upon me by job availability and hiring requirements. I have yet to see a job posting for a fresh-off-the-boat C developer. It's nearly always 5-10 years industry-related experience required. Web, on the other hand, seems more willing to take on the new guys.
  • agumonkey 9y ago
    even MIT caved in, using python + libs in courses. They clearly said: today people are wiring solutions. I find it a bit problematic because when there's no solution you feel lost. But they have decades of experience .. I hope it's their very best insight.
  • photonios 9y ago
    Honestly, I think you underestimate things a bit. In a "modern" development stack you rely on a lot of work by others. But it's far from the "glorified plumbing" you describe. It's not as black and white as you describe it to be.
    • soundwave106 9y ago
      To me, your basic "high level programming" job (which usually includes the JS folks with their modern stacks) typically is all about translating business / application requirements into logic that computers can understand and interfaces that people can use. Certainly, as a higher level programmer, I do think it is great to know as much lower level concepts as possible (it helps your higher level programming skills). But the truth is, business simply wants to Get Shit Done Fast. And having frameworks or libraries do a lot of the work for you saves a lot of time. Hence the huge amount of usage of "glorified plumbing" in the field. (I don't think even C++ folks are immune to the "glorified plumbing" effect, eg: they have Boost, Poco, QT, etc.) As far as I know, the separation between this side of programming and the more mathematical / inner detail "engineering" oriented side has always existed. (When I went to college, the "higher programming" pathway also had business courses, where the "engineering" side concentrated more on algorithms and the like. Now, even the business programmer folks did take one course in C++ back then...)
  • jsudhams 9y ago
    We do have programmer, developer and engineer. I assume the framework developer will come in league of developer while the user is programmer http://chrislema.com/programmer-developer-engineer/ http://chrislema.com/programmer-developer-engineer/
• archagon 9y ago
  OK? Sounds like "learning" at work to me. Besides, things are better grokked when explained from a variety of angles, be they top down or bottom up.
• agumonkey 9y ago
  All this screams to me "education". The self taught diy thing is great, but on mass scale it's inefficient. If all these devs (I could include myself) could spend 6 months doing all this together sharing the common patterns and then go out fixing other problems ? Also SICP/HtDP
  • chickenfries 9y ago
    One, who just has a free 6 months? Two, do you honestly think you can fit a comprehensive CS education that would satisfy people like you in six months?
    • agumonkey 9y ago
      Good points but what these people learn in segments in random order would probably fit into 6 months. I don't even believe CS education fits in 5 years anyway. I was just trying to suggest how to avoid diy lib chaos.
    • throwawayjava 9y ago
      1. Most westerners born outside the USA. And in the USA anyone willing to take out a loan. 2. The core requirements for a cs major at a typical university (read: not CMU,MIT,Stanford,Berkeley) and especially at a non flagship is basically 4 or 5 courses, which you can for sure cram into 6 months if that's all you're studying. Personally, I'd rather work with people who learn some part of that on their own (or even not at all) but have a stellar education in reading, writing, and math. The former are often provided by good high schools. The latter not so much. At least in the states. But if all you want is just the core fragment of just the cs, six intense months are enough.
      • pjmlp 9y ago
        Having a 5 year degree in Informatics Engineering, I doubt very much you could cram that much in 6 months. Not at my university, with the amount of stuff we had to do, unless in the 20+ years that have gone by, they got the quality level down.
• jnbiche 9y ago
  > The more I read, the more I felt that the author was long-windedly discovering FSM's Then you missed the main point of the post, which was event flow, not state management. I'm wondering if sometimes older devs (I'm one) read these posts in anticipation, just waiting to find something that they recognize from elsewhere, just so they can say "aha, that's just X, nothing more!". In this case, you did recognize that yes, you can use a FSM to store application state, but the point of the article was much more event flow, specifically unidirectional UI architecture. It's not a new thing, by any means, but I thought it was a well-written post on how she/he expanded their understanding of this pattern. > giving it all a new fancy name, and blogging about it Are you suggesting that in this case, unidirectional UI flow is just another name for a FSM?
  • LolWolf 9y ago
    I guess technically everything physical is an FSM with enough states, but that wouldn't be a particularly strong statement. That being said, I'd argue a lot of such posts are of that form (one big idea that's well-known in TCS) modulo some amount of additional cool/novel/well-exposed/interesting stuff I didn't know before (the latter of which is what I really read the post for).
  • mmjaa 9y ago
    >Are you suggesting that in this case, unidirectional UI flow is just another name for a FSM? Yup. The UI reads its current-state data, which comes in on an event queue, and renders the display accordingly. This is a state machine.
    • jnbiche 9y ago
      Well, as someone else said, just about anything physical could be modeled as a state machine. That doesn't mean we use the term state machine to describe just about everything physical. Are you seriously suggesting we abandon terms like "unidirectional UI flow" and just describe those architectures as state machines? You would be missing the most important part of the term, which is the flow of events. State machine says nothing about that. I mean, if you're reducing the event flow of a UI to a state machine, why use the term MVC, right? It's just a state machine at heart, right? A lexer? Oh, that's just a state machine, forget about the term lexer. The various Markov models? Oh, just a state machine. etc. etc.
• landave 9y ago
  I couldn't agree more, and I've always been a strong advocate of learning things bottom up, as opposed to top down. However, it always amazes me how powerful abstractions such as high-level languages are. In particular, it allows people who know virtually nothing about the underlying mechanisms to develop cool applications. This is a great thing, and I think we should value it, even though it comes with some major problems.
• alacombe 9y ago
  There is plenty to re-use in C, eg. BSD's queue.h or linux' list.h for linked list alone. Because the author choose not to do so doesn't mean it is the fate of the whole language. Though, it is indeed a little harder than firing "npm".
  • Nursie 9y ago
    Is it? On (Debian) linux boxes apt-get install <package>-dev and away you go, there's literally the whole platform ecosystem there for you to use.
    • deleted 9y ago
      [deleted]
    • deleted 9y ago
      [deleted]
• noxToken 9y ago
  > I'm not trying to be overly critical, but for a lot of us, "discovering that C-based apps are, weirdly, similar to what us React-ites are doing" sure seems like a step backwards from real stack competency. This is something that I try to impart on all new hires. Collective we have been making great strides in this industry lately, and in my experience, the more inexperience devs tend to get blinded by all of the shiny. This isn't inherently bad; a lot of CS breakthroughs are tough to learn without the appropriate domain knowledge. But practical stuff that most devs use ins't anything fancy. It's the same concepts from years ago with config files attached to it. We don't stress learning algorithms so that you can write a perfect quicksort implementation from memory. We want you to know the fundamentals so that tomorrows new technology becomes trivial to learn.
• sametmax 9y ago
  The reverse is true. I meet quite a lot of low to middle level programmers that stick to what they know because it's "the basics", and hence completely lack in experience in: 1 - Writing elegant modern code Working with experienced C / Java coders to write proper Python is a challenge. They tend to use twice to many lines, ending up with slower and less readable code. They don't use the additional productivity to produce cheap goodies like generated doc, more unit tests, etc. They over-engineer stuff, but let the user experience down. And don't ask them to setup a server without the help of a sysadmin. 2 - Trading efficiently machine time for coder time Aka you cost 100 $/h, a bigger server cost the same amount a month. Keep the double nested loop and go code something else. And please setup code auto reload and preprocessors. Because THAT will save time and money down the road. 3 - Knowing the modern ecosystem and how the stacks fit together No you don't need share this across threads and set a mutex here, put that in redis. Don't write that in XML, you have JSON/YAML/TOML for that. Actually don't write that in a file, you have sqlite. No, you don't want to JOIN that, you have Arrays and JSON types in PostGres. If you got a lot of those, mongo or elastic search will do. No you don't write sockets manually, you have http, zeromq, wamp and the likes to do 99% of the jobs. JSON is too slow ? You have bson, msgpack, protocol buffers... Yeah, this ORM is slow. But it generates the entire validation system, including HTML forms. And it allows for 12 plugins to share a common API to provide auth, history, permissions, registrations, a REST API, security measures, sanitizing and data validation for free. Plus the server has 32 cores so just go with it. 4 - being able to keep up with user expectations No I have no idea how to code in assemble. I can tell you however that the search completion you don't want to add here because it's too much work would prevent the user to think your app is from 2004. And I can get decently performance version of it for tomorrow at a cost effective price. ---- Bottom line, everybody has limited time and resources and can only learn so many things at once. Also different industries have different needs. And sometime you want low level programmers, sometime you want high level programmers. One could hire somebody who has the skills of both, but you probably can't afford him or her. And he/she is probably not interested this mission anyway
  • nv-vn 9y ago
    There's a lot I could address with your comment, but since I'm short on time here, where are you getting servers that they all cost the same amount regardless of specs?
• fnl 9y ago
  I don't think the article was that bad for "junior-JS-to-JS-dev talk", which I think is clearly the main audience. Yes, I'd agree, for any seasoned dev, an article about the basics of functional programming, state machines, and the basics of unit testing and API design is a tad boring ;-). But that's no reason to get that upset about an article that clearly wasn't written for such an audience. Rather, such a response is not exactly encouraging those "kids" to learn complex programming concepts/languages in the first place, I think, and instead seems a bit offensive, to be honest.
  • jnbiche 9y ago
    > such a response is not exactly encouraging those "kids" to learn complex programming concepts/languages in the first place, I think, and instead seems a bit offensive, to be honest. Yes, exactly. I mean, this dev is someone who clearly is working toward a deeper level of understanding of CS concepts, and here some people seem to be criticizing him for that. It's frustrating.
    • MrBingley 9y ago
      Ah, but you forget, then we can't browbeat the JavaScript-kiddies with our own seasoned superiority. (adjusts monocle)
      • fnl 9y ago
        Hmm; I guess that means a solution would be to personalize HN rankings on the similarity of voters' earlier votes on other articles with your own voting behavior (as a proxy for article preference...) :-)
    • zbtaylor1 9y ago
      > It's frustrating. It really is. This "community" can be very unwelcoming. I'll never understand what motivates people to shit all over content they consider below them. Is it really that hard to pass by without shouting "I'm smarter than you!" at everyone?
• donkeyd 9y ago
  I consider myself a self-taught professional developer, since it's become the job that pays my bills, but I've never had any formal education on the subject. I regularly find out things like this, because I haven't been educated on the subject and because I don't have infinite spare time to study programming patterns. I know they exist and when I feel the need to, I look them up, but otherwise, yeah; "npm -i <all the things>" all the time. I don't feel bad about this at all, since my colleagues describe me as a competent developer and my employer can't find enough people for all the work we have to do. If we only wanted to hire developers who understand C, we'd have a really big issue.
• yaseer 9y ago
  Is this the state of things today...from the top-down, trickle through the stack learning 'the things' Yes, the path most people will take today is from high-level languages and high-level abstractions, down to low level abstractions. It's not any better or worse than a bottom-up approach for learning. The fact that people are going down through the stack, trying to learn and understand things as they go is to be celebrated, not to be rued. A top-down approach for learning makes logical and logistical sense in 2017, given the demand for developers operating on high-level abstractions. The bottom-up approach made sense, circa 1972 when C appeared. Neither approach is 'better', IMO.
  • taneq 9y ago
    My grandad used to say if you learn to sail a small boat properly, you can then learn to sail a big boat, but if you learn to sail a big boat first, you'll never really learn to sail a small boat properly. I think the analogy holds here.
    • eecc 9y ago
      Well, what counts as big and small in this case? C or Js?
      • 1_player 9y ago
        I suppose small == low level (C), big == high level (JS)
    • Sacho 9y ago
      Why can't you learn to sail a small boat properly after learning to sail a big boat? I don't see how the example works in the first place.
      • smallhands 9y ago
        what the grandfather is trying to say by my own understand is learning to sail small boat when big boat sinks small boat sailing skill is the only thing that will save your hide.the old man is wise
• njharman 9y ago
  > Is this the state of things today I don't think that is just today (except the blogging aspect). That is how it always has been. Developers learn from experience, learn from doing.
• dvfjsdhgfv 9y ago
  It's a general trend. Many young developers rediscover old things and describe them using familiar terms. At first it amazed me, then I understood it's more or less natural and there's nothing we can do. It's like when your son discovers the Beatles and gets excited.
• Raphmedia 9y ago
  What can I say? Learning the language du-jour landed me a high paying job right out of school. I had a choice at one point : Join the workforce doing web work (and make money right now) vs. spend more time in school and learn more while gaining debts and making no money. Right now I am debt free, living a good life writing modern JS. In my free time, I try to learn more low-level CS knowledge. It's however hard to justify the time spent doing this since none of it is of use during my day job. If University was free and we didn't have to work to eat, I would know everything from the ground up. Sadly, this is not the world we live in.