1. 8
    • CVS source repo
    • DLNA Server for the tunes
    • DNS
    • IMAP
    • Mosquito to revive weather reports from remote sensors
    • Mumble
    • My MUD Server
    • My MUD client software
    • NextCloud
    • NFS
    • Password hashing app
    • Roundcube Web Mail
    • SMB
    • SMTP
    • Web servers for two domains
    • Weewx Weather Station
    1. 2

      What’s your MUD?

    1. 4

      Their design on this is so good imho

      1. 6

        It’s pretty but it hurts my eyes to read

        1. 1

          I have slight dyslexia. I am quite sure that headache from reading that site is not worth it.

        2. 2

          I bet if you were in the group

          "browsers": [ ">0.25%", "not ie 11", "not op_mini all" ]

          it would really look awesome. Time to upgrade! ☺

        1. 10

          I think Tcl counts:

          The way tcl works: a line of code is parsed once. Only once. Only ever once. Once, once, once. No exceptions at all. None. Zero. Zip. Nada. After substitutions are performed the first word becomes the command and all the other words become the arguments. Always. Always, always. Always.

          Source: https://wiki.tcl.tk/12927

          Sounds like an AST to me.

          1. 2

            Yes, Tcl is even worse than shell, because it dynamically parses code everywhere. Everything is a string, including code. This is useful for Lisp-ish metaprogramming, but it’s also inefficient:

            https://www.usenix.org/legacy/publications/library/proceedings/tcl96/full_papers/lewis/lewis.html

            The two main sources of performance problems in the current Tcl system (Tcl 7.5) are script reparsing and conversions between strings and other data representations. The current interpreter spends as much as 50% of its time parsing. It reparses the body of a loop, for example, on each iteration.

            So really it’s not even an AST interpreter – it’s an interpreter that parses on the fly.

            1. 14

              Tcl has been on-the-fly bytecode compiled and internally typed since version 8.0, which was released twenty one years ago.

              1. 1

                Yup, the “stringly typed” nature of Tcl made me think of it first. Like wrapping every line of code in eval :D

            1. 4

              Putting the final touches on UTF-8 input and output support for The Last Outpost MUD. We’re looking for more players, so when its time to take a break from whatever you’ve been working on this week, come over and explore some dungeons with us– now with umlauts!

              Also, just for fun, I added a ‘baudrate’ command into the game. Chose among your favorite modem rates (56k bps or lower), and you can try playing our mulit-user text adventure game just like it was when it first went online back in 1991, minus the occasional burst of line noise and your mom yelling at you to get off the phone.

              1. 11

                This article has a very low quality: it reports on two not interesting facts (retrieving code via http and loading a DLL from current directory). Why is it upvoted so much?

                1. 14

                  Two relevant points at least: (1) an unverified binary is downloaded and installed and (2) on Windows outdated and likely exploitable versions of OpenVPN and OpenSSL are installed.

                  Then there’s the other more trivial stuff in the article that may or may not be interesting.

                  Despite the abrupt nature of the article, it seems worth talking about.

                  1. 4

                    Yeah, I’m kind of appalled that the author completely glanced over the setup step where you download the script asking you to send your password over an unsecured connection. Forget about a man in the middle attack that switches the script, all you need is to log the HTTP requests and you get the user’s password.

                    1. 4

                      They seem to stop because “they couldn’t be bothered” right where things could be about to get interesting. Which is fine ofc, that’s their prerogative, but it leads to a largely uninformative article.

                      1. 1

                        Yeah, something has got to be wrong here. How can an article have 49 upvotes but not a single comment in its first 13 hours?

                        1. 8

                          It’s an interesting find but not super engaging. It’s gross incompetence with very much not industry best practices. There isn’t much to learn from this other than “don’t write sketchy code”.

                      1. 2

                        A great thing. If you have the time/will/energy you could de-yellow the chassis to make it complete ;).

                        1. 6

                          Here’s a wayback to instructions for mixing up a batch of Retr0brite if you are interested.

                        1. -4

                          TL;DR - Computer science student discovers something that he thought was simple is, in fact, not so simple. Millennial Outrage ensues.

                          1. 11

                            Software engineer with a masters in computer science, who has fixed bugs in several pathing libraries, talks about how pathing is weird in a lot of facepalming ways, where most other things that we think are “simple but not” are human systems like time and names while this is something programmers created for other programmers and still managed to make it overly complicated. Is written off because he’s a “millennial”.

                            1. 4

                              If the author had written his post in the form of “here are some unexpected consequences of the POSIX path standard that might trip you up” instead of coming across as someone who’s never worked with Unix paths before, the reactions might have been more positive.

                              1. 2

                                I would have serious reservations using a path library that was “fixed” in some way by escaping dots with a backslash.

                              2. 3

                                Your ageism is not welcome here.

                              1. 4

                                Don’t get me wrong here, the author certainly isn’t wrong, I just don’t see the point of the article. I expected the article to launch into an exploration of how we could fix this without losing legacy support but instead the article just ended.

                                1. 2

                                  Yeah, seriously. There’s no need to shout your bug report into the void… take it to vim-dev@vim.org where it belongs.

                                1. 9

                                  It turns out the machines that feel quick are actually quick, much quicker than my modern computer – computers from the 70s and 80s commonly have keypress-to-screen-update latencies in the 30ms to 50ms range out of the box, whereas modern computers are usually in the 100ms to 200ms range.

                                  This makes me sad.

                                  Updated to add: if the original author is reading this, I have some 1990s Models M and a modern Unicomp (Model M remake built by the original IBM contractor) and I’d be really interested in seeing how they compare. I am in NYC and would be happy to lend them to you. But your “please contact me” link goes to Twitter (of which I am not a member), so please e-mail me if you are interested.

                                  1. 3

                                    For the 90s keyboards, you might want to measure the latency coming out of the original interface, then as it goes through a PS/2->USB converter (or in my case, an AT->PS/2->USB converter).

                                    1. 1

                                      Heh. I used a single “Windows 98 ready!” Logitech NewTouch ergo keyboard with an integrated touchpad for the bulk of my career, taking it with me from job to job. Best keyboard feel I ever found, and completely indestructible. I can’t speak to its latency, but its longevity was legendary – six jobs, sixteen years, and who knows how many lines of code.

                                      The series of keyboard connectors that I had to use to keep it running got pretty ludicrous though, and I remember that a crummy ps/2 to usb converter did seem to change how responsive the keyboard felt. It was worth it to suffer the return line at Fry’s to find good ones.

                                    2. 2

                                      Models M

                                      Thank you for your proper pluralization.

                                    1. 19

                                      TL;DR - Author brought on by CIO as outside consultant to deflect career ending blame for failed project onto single, unlikable employee, saving multiple layers of incompetent management from same fate. Author appears not to understand this ruse, and is proud to write about his role in it.

                                      1. 5

                                        I also know that some startups offer below average salary, because of options you get as an employee when joining a startup.

                                        1. 8

                                          This is kind of the same thing though, isn’t it? Options are worthless until there is a liquidation event. By not calling this out, the employer is hoping you’ll add the potential value of the options to your salary to get total comp, but they’re still underpaying you.

                                          1. 0

                                            Yes, exactly. It’s “virtual” money. It’s one of those things i don’t get why founder try to do such things to the employees.

                                          2. 8

                                            As I once said elsewhere:

                                            Stock options are for when you want to tightly couple your career and investing decisions at a moment when you’re excited and biased and trying to please someone who can offer or deny you a job.

                                            Before taking options, maybe ask yourself if you’d invest in this company if you weren’t going to work there.

                                            Personally, I consider stock options to be basically worthless, because:

                                            • Most companies fail.
                                            • Success or failure depends more on business decisions than on my individual code contributions.
                                            • Stock options can be complicated and sometimes employees get the short end of the stick vs outside investors
                                            • Having options would complicate my decision about when to leave a job for other reasons

                                            Getting paid in options makes me an investor in the business, and investing in individual stocks is always risky. Getting paid in cash means I have zero risk, and can invest in mutual funds or whatever seems prudent to me.

                                            1. 3

                                              True, the salary is lower but the expected value of the compensation isn’t usually different. Here’s how it works.

                                              Lets say you have a job that pays you $100k a year, no bonuses, and no option to buy into the company. How much do you expect to have been paid after four years, barring any promotions or raises? That’s $100k/yr * 4yr = $400k.

                                              Now suppose you have a different job. It only pays $90k a year, but you get to buy a .001 ownership stake in the company at negligible cost on a four year vest. There’s an 80% chance that the company will fail and go bust when it runs out of money after year four, but a 20% chance that the company could get sold outright for $200M. What do you expect to have been paid after four years?

                                              There are two possibilities. If the company goes bust, you get $90k/yr * 4yr = $360k. If the company is successfully sold, you get your $360k salary plus an additional $200k from the sale of your share of the company, for a total of $560k.

                                              Since you have probabilities for the two outcomes, you can calculate the expected value. You have a 20% chance of earning $560k, and an 80% chance of earning $360. (20% * $560k) + (80% * $360) = $400k.

                                              So the salary in the second job is 10% lower, but the expected pay after four years is exactly the same.

                                              What makes optioned offers so difficult to evaluate is the uncertainty in assigning the odds and payouts of success. Are the odds of liquidity really as high as %20, and will the company really sell for $200M? Or is it more like a 10% chance at a $500M sale? And is that better or worse? Expected value lets you weigh those options.

                                              1. 3

                                                What makes optioned offers so difficult to evaluate is the uncertainty in assigning the odds and payouts of success. Are the odds of liquidity really as high as %20, and will the company really sell for $200M? Or is it more like a 10% chance at a $500M sale?

                                                That’s my problem: either of those numbers could be anything.

                                                Also, imagine the stock and job being decoupled: you don’t work at this company, but you have the chance to invest $10k, with 80% odds of losing it entirely. Would you? I wouldn’t.

                                                you get to buy a .001 ownership stake in the company at negligible cost on a four year vest.

                                                Complication: what happens if you want to leave the job after 2 years? So far I haven’t had a 4-year job in tech.

                                                1. 1

                                                  That’s my problem: either of those numbers could be anything.

                                                  Like a lot of things, it takes explanation and practice to get a feel for how it works, but the numbers really can’t be anything.

                                                  Its fairly common knowledge that nine out of ten startups fail outright. So a ten percent success rate is a pretty reasonable probability to assign if you know absolutely nothing else. The valuation range at liquidity is pretty limited too. A valuation higher than $500M would be outstanding, but $100M to $200M is a lot more common and a safer bet, again if you know nothing else. One way to get a better estimate than that is simply to ask what the founders think. They have to answer that question for investors all the time. Yes, it might be wildly optimistic, but at least you can use it as an upper limit.

                                                  Also, imagine the stock and job being decoupled: you don’t work at this company, but you have the chance to invest $10k, with 80% odds of losing it entirely. Would you? I wouldn’t.

                                                  Obviously if you can’t afford to be without the $10k for the investment period, or forever, you cant take that bet. But if we’re still talking about a payout on success of $200k with a confident 80% failure estimate, then the expected value math says its a good deal, and I’d certainly take it if I could afford to be without the $10k.

                                                  However, those kind of deals (small, lucrative) are usually only made available to employees, as one of the benefits for doing work with the startup. If you evaluated the company and wanted in on the deal, but for some reason didn’t want to work there, you’d have to come up with a much bigger ‘put’ than $10k to buy into it. Think ten times that amount, if they wanted funding partners at all.

                                                  Complication: what happens if you want to leave the job after 2 years? So far I haven’t had a 4-year job in tech.

                                                  Most companies that aren’t on an immanent failure course will simply exercise their “right of first buyback” on your shares. You’ll get back whatever money you paid for them, and you’ll walk away from the job having made whatever your salary was for those two years.

                                            1. 5

                                              The link is actually an advertisment for the author’s book, “The Programmer’s Guide to a Sane Workweek”, so be sure to take what is written there with a grain of salt.

                                              Job postings are written in code. You can’t ignore the source of the posting, focus only at one or two statements in it, and expect to have deciphered the correct message.

                                              The particular job postings that I believe the author is writing about are for software engineers at what looks to be a less-than-ten employee startup in it first months of operation.

                                              It’s not a posting for “established mega-corp looking for wage slaves to exploit in dreary sweatshop environment” as the author would have you believe, and they aren’t really looking for individual contributor programmers. What I read there is, “risky venture seeks to hire technical management and architecture team.”

                                              If you are an ambitious engineer with aspirations toward management, are willing to code until there enough people on board to justify a managment position, and are willing to work hard up front in trade for significant career advancement and pay increase in a future that may or may not materialize, then maybe this is an opportunity for you to consider.

                                              Sure, if you go to a startup like that you’ll probably get paid less on an hourly basis for the first few years than you would have made writing code at big company, simply because you’ll put in more hours. But, if the company grows and your career grows with it, you’ll be making management money a lot faster than you might otherwise have at the big company job.

                                              1. 4

                                                The story link is to an opinion based on a summary page that was written for a security research paper, so I’m suggesting “rant”. The source material is pretty interesting, however.

                                                If you aren’t into computer or network security, you might not realize that SSL data can be legitimately intercepted and scanned for vulnerabilities by your security systems. The authors of the paper explore how prevalent that has become.

                                                Here’s a link to a summary page written by one of the authors of the paper:

                                                Understanding the prevalence of web traffic interception

                                                And here’s a PDF link to the actual paper, which is the better read:

                                                The Security Impact of HTTPS Interception

                                                I think the conclusions they make about prevalence of malware may not be justified by the data, given that they identified 24 different legitimate scanning systems but could only fingerprint six of them, but I agree strongly with the final conclusion- If you are going to install a network middlebox, you’d better make absolutely sure that you are comfortable with how it handles it’s end of the connection security. These products may apply different security standards, and many of them are not an upgrade over what an endpoint might do on its own.

                                                1. 1

                                                  You don’t have to be one of those dreaded “capitalist bootlicker apologists” to recognize that inspecting inbound and outbound traffic (of their devices on their network) makes sense from a security perspective.

                                                1. 15

                                                  I haven’t read his C guide, but I really enjoyed Beej’s Guide to Network Programming when I refactored The Last Outpost MUD for IPv6 support. He’s got a fun and informative writing style. The material is not so dumbed down as to be useless as a reference, and not so detailed as to be hard to figure out the basics. There are lots of code examples there too.

                                                  I’d say its a nice companion to the man pages.

                                                  1. 9

                                                    That’s very cool! Writing an online resume builder was my very first job out of university, way back before there was a Web– it was a terminal based program. Amit, consider adding an ‘upload my resume for recruitment searches’ and a subscription based service for head hunters, you’ll have yourself a little business there!

                                                    1. 3

                                                      Thanks malakai! I’ll surely think about in that direction.

                                                    1. 6

                                                      I’ll add to this that being on call when it’s quiet limits your ability to live your life as you please outside of office hours - you can’t disappear into the wilderness, you can’t go to the movies and turn your phone off, you can’t go out to dinner and not take your laptop, you can’t go out to a party and get drunk so that you sleep through the beeping.

                                                      That’s the best scenario. When things are broken you might lose a lot of sleep. You might have to interrupt dinner with friends. You might have to jump in a cab and head home so you can get properly online and work. You come into the office tired; your partner is grumpy because they got woken up, too; you feel like crap because you haven’t had an evening all week where you didn’t have to deal with something.

                                                      On-call can be a scourge. It’s random, unpaid work, demanding your full attention at the worst of times. The best thing I can recommend is: don’t be on call. Don’t get in that critical path. If you are a manager with on-call staff you should be telling people to come in late, or not at all, if they’ve had a night of activity.

                                                      And make fixing that issue so it never wakes anyone up again your biggest priority.

                                                      1. 4

                                                        It’s random, unpaid work, demanding your full attention at the worst of times.

                                                        Is this something specific to states? Where I live I’m paid (constant amount) for the fact that I’m on-call even if nothing happens. And 150% of my hourly rate if I have to work.

                                                        1. 6

                                                          In the US, it varies by the job and by the state.

                                                          Some employees are paid hourly, and there are state and federal labor rules about how many hours a week (and sometimes how many hours per day) an employee can work before an overtime rate has to be paid.

                                                          There are other workers, however, who are paid ‘on salary’ instead of hourly. That means they get payed monthly or bi-weekly at a fixed rate, and hours worked aren’t tracked and don’t enter into the pay equation. They are called ‘exempt’ employees, because they are not covered by the minimum wage and overtime rules that apply to hourly employees under the Fair Labor Standards Act.

                                                          Exempt employees often preferentially asked to go on call because, if they’ll do it, they aren’t required to be paid extra for the work like an hourly employee would be. Some jobs choose to pay their exempt employees an on-call bonus, or to compensate them in other ways- extra time off for example- but not all do. If you work at one of those places, you have to decide if your salary makes up for the hassle and inconvenience of putting up with on-call work.

                                                          1. 3

                                                            In the US, by an unfortunate quirk of labor regulations, software engineers are considered “clerical” and are exempt from the requirement that they be paid overtime. Consequently, for all intents and purposes all are salaried and not paid for hours actually worked.

                                                            1. 2

                                                              Yeah, likewise. I’m a massive advocate for putting devs on-call, but I won’t enter a rotation unless it’s compensated: at a minimum, a base rate per hour, regardless of incidents.

                                                              1. 2

                                                                In the US there are a lot more people working as salaried, non-hourly employees than other places I’m aware of in europe and SE asia. It’s rare for a salaried job to pay any sort of overtime, or additional compensation for on-call.

                                                              2. 3

                                                                All places I’ve worked at, including startups and small companies paid for you to be on call. And you matched hours to hours if there was night work (ie come in late next day), and you got an extra day off at the end of your on call shift.

                                                              1. 8

                                                                Don’t give up. Work is hard! That’s why its not called play.

                                                                I’m a random internet guy who worked. I’ve been in individual contributor roles from New Useless Guy to Senior Staff Engineer, and every management role from Team Lead to Engineering VP. Here is a piece of advice that was given to me early in my career. I found it to be very useful to me in every job that I’ve taken on, so will I pass it on to you:

                                                                You should always submit a weekly status report to your boss, even if they don’t ask you for it, and always have a 30 minute one-on-one weekly meeting to discuss it, even if neither of you really want to or if you feel there is nothing to discuss. At the end of that meeting, ask these two questions of your boss: “Is there anything I should be doing more or less of?”, and “Is there anything I could be doing better?”

                                                                There’s a few reasons you should to do this. If you write a weekly status report, you’ll have to keep a daily journal. If you have attention, concentration, or organization problems, just writing down what you did at the end of the day and what you hope to accomplish tomorrow will help you a ton.

                                                                Another reason for the report and the meeting is that you want your boss to be constantly reminded about the value that you bring. You want your boss to be able to discuss your work when his or her boss asks what’s going on, because it makes both of you look good.

                                                                You also want your boss to know when your workload is getting you down. If you have a weekly meeting you won’t ever have to explicitly say that your load is too much. a reasonable boss will be able to tell from your weekly status report and from talking to you if you are starting to get overloaded.

                                                                You are right about not wanting to argue with the boss- certainly you don’t do that in public. But any boss that won’t listen to your concerns and explain their reasoning for a decision to you in a one-on-one is probably not someone you want to work for. Asking questions helps your boss as much as it helps you. Your concerns might not change their mind, but hearing them helps your boss be ready with an answer the next time someone asks about it- and maybe that someone is their own boss.

                                                                Make a ritual of asking the “more/less” and “what can I do better” questions at the end of your weekly meeting. You will probably get an “I don’t know” out of your boss most of the time, and that ends the meeting, but eventually, you’ll get an answer. Maybe because you did something unexpectedly great, maybe because you screwed up a little bit. Asking the questions every time shows that you are always open to both praise and criticism, that you actually expect both, and in return you are willing to change for the better. That alone makes you a valuable employee, and will keep you from being at the top of the layoff list when the cuts eventually come.

                                                                Getting the “I don’t know” answer is important too, because it lets you know that expectations are being met. There is no reason to stay up at night worrying when you know the boss is happy, right?

                                                                Finally, if you are working for someone who won’t read your report, or won’t give you that 30 minutes a week, you need to not work for that person. They’ll never be on your side, your career will suffer, and you aren’t ever going to be happy there. Find someone to work with not for.

                                                                Anyway… thats my rando internet guy career advice for the week. Good luck out there, little lobster.

                                                                1. 1

                                                                  always have a 30 minute one-on-one weekly meeting to discuss it, even if neither of you really want to or if you feel there is nothing to discuss

                                                                  Why? If there actually is nothing to do discuss, it’s a complete waste of time, is it not?

                                                                  It’s not useful to “make” something to discuss either. It’s a bit like a government bureaucrat coming up with some pointless busywork for himself, just to project the appearance that he’s being productive.

                                                                  Finally, if you are working for someone who won’t read your report, or won’t give you that 30 minutes a week, you need to not work for that person. They’ll never be on your side, your career will suffer, and you aren’t ever going to be happy there

                                                                  If that practice were actually a good idea, you’d want the whole team to do it, right? Suppose the boss has 10 people reporting to him. He’d need to carve out 5 hours of his week for those 30-min sessions that probably won’t be useful anyway. Do you think that’s feasible?

                                                                  1. 2

                                                                    Why? If there actually is nothing to do discuss, it’s a complete waste of time, is it not?

                                                                    It’s not useful to “make” something to discuss either. It’s a bit like a government bureaucrat coming up with some pointless busywork for himself, just to project the appearance that he’s being productive.

                                                                    No! It is not a complete waste of time! If nothing else, it assures you that your boss has heard what you’re working on- and that the boss knows you are in fact working on something. For people who sometimes lack good focus, just knowing that there is a short meeting with the boss coming up is enough to motivation to at least think about and appreciate what they are doing and what they’ve done, and that’s great for self worth and feeling good about your work.

                                                                    Sometimes there might not be a lot of new things to talk about, maybe its the same status as last week. In that case… a little “how you holding up” talk is good. Or “here’s something to look forward to when you are done with this slog” helps out. Or maybe it gives the boss a chance to ask you in private, “do you need help, or do you just need time on this?”

                                                                    The point is, programming is a heads down job, and you may not get a whole lot of time to interact with your boss day to day. My experience is that if you (as a manager or as an employee) don’t set aside a block of time each week to make that personal interaction happen, it won’t happen on its own, and your job satisfaction will suffer.

                                                                    If that practice were actually a good idea, you’d want the whole team to do it, right? Suppose the boss has 10 people reporting to him. He’d need to carve out 5 hours of his week for those 30-min sessions that probably won’t be useful anyway. Do you think that’s feasible?

                                                                    Well, it certainly is a good idea, and it is not only feasible, its a common industry practice. What do you think managers do for a living? They manage people. Five hours out of a week for scheduled personal time with ten employees isn’t a big time investment.

                                                                    And yes, for the last twenty years, every one of my direct reports got a scheduled weekly meeting with me, and so did every one of my bosses- at that jobs I chose to stay at. :)

                                                                1. 7

                                                                  Problem is, many newcomers, kids and adults alike, believe that code is inherently complex simply because it looks complex. Our first challenge became ‘How do we make code look friendly?’

                                                                  Go back to the start of the personal computer era and you’ll find plenty of books that made code look “friendly” without completely divorcing programming from what it is- an exercise in thinking clearly about steps and writing them down. Here are two great examples:

                                                                  Getting Started With TRS-80 Basic

                                                                  Personal Computing On The VIC-20 - A Friendly Guide

                                                                  I credit those as being two of the most influential texts of my programming career. They put me on the path, and I read ’em when I was nine years old.

                                                                  1. 5

                                                                    I was a longtime professional TCL programmer. As an old timer, I’d say there were a couple of big things that really hurt the language.

                                                                    TCL has awesome dynamic typing but its early implementation was notoriously slow. It was dramatically improved over time, and the language got a JIT bytecode compiler in version 8 in ‘97, but by then the language had been in use for seven years, and opinions had been formed. While today’s TCL is fast, its reputation for slowness was set in stone.

                                                                    TCL was easy to embed in other projects, but it used to be very difficult to bring other projects into TCL. If you wanted to use the powerful commands added by Expect, you had to run Expect to execute your TCL. If you wanted to make a GUI with Tk, you needed to run your TCL under the WISH executable. If you wanted to script up tests using vendor A’s test hardware, you ran your TCL under vendor A’s custom TCL interpreter. Want to put all three into one program? Nope. The ease of embedding TCL into executables was great, but it slowed down the addition of external library/package support into the language.

                                                                    As mentioned in the article, TCL has this great ability to extend its own language syntax at run time. I used it many times to provide ease of use constructs and sand boxing in the test harnesses that I developed. Another great example of the language modifying ability was the [incr tcl] extensions. Announced in ‘93, they added true object oriented structure to the language, just by loading the incrTcl package. I can’t imaging working on a large TCL project without [incr tcl]. However, because you could load the extensions when you wanted to use them, they never needed to become an official part of the language. In fact, there were several different, incompatible OO systems developed for TCL. Instead of bringing more programmers into the fold, that flexibility really just served to fragment the language into different dialects and camps.

                                                                    I think the biggest one was Sun Microsystems deciding that it was going “all in” on Java for everything. The people at Sun that had been developing, researching, using, and promoting the language suddenly found themselves on the wrong side of the fence, and faced significant pressure to leave TCL alone and get in line with the Java vision. Without a strong group of leaders to direct and promote the language, its decline in popularity was inevitable.

                                                                    1. 1

                                                                      Sounds like its history has some similarities with LISP vs imperative 3GL’s. Appreciate the insights. The other one in this category is Rebol with its descendant Red. I always think of LISP, Rebol, and Tcl together for simple, flexible and productive languages. I mean, one could throw real meta-languages like META II in there, too. I just didn’t know about it back then.

                                                                    1. 3

                                                                      While it is not immediately obvious to most people when they start thinking about doing test metrics for the first time, it just as important to monitor for performance improvement as it is to watch for degradation. If the execution time of a test unexpectedly goes down and the test still passes, it may be that some upstream developer has quietly done an optimization somewhere, or it may be an indication that some aspect of the action under test isn’t happening correctly anymore and the test isn’t detecting the failure. Either way, you’ve got an issue to diagnose, just as if the execution time had suddenly increased.