keithb-

Normally I skim these write-ups and then move on, but something about this time finds me exhausted. Enough already. I was a huge proponent of XML and back in the day I would also evangelize its capabilities, its malleability. "What a great language for defining data structures that isn't tied to any physical storage requirements." Regex and enum restrictions on attribute values? Okay cool. Substitution groups? Woah. But then y'all started saying "I can't read this" and "angle brackets are too expensive" and suddenly the XML wave just receded back into automotive and logistics, and the world stopped complaining.

I think it is time to accept that the world doesn't need Lisp. It might be your passion. It might just click with your way of thinking. That's all great, but it is still an existential crisis and you need to deal with it. The world is humming along just as well without esperanto and if it completely disappeared from monthly meetups, the world wouldn't notice.

Trust me, I have been to the brink of destruction and waking up the next day is hard, but I have lived it and I know: it is possible to leave behind those things that you think define your being, your identity. You will not fade away completely. Instead, you will find that your existence can have meaning in other forms.

Oh I see you brought a chess board to a basketball game. Okay cool, but just set that down and let's see if we can still have fun with this other game.

I tend to agree with you: this did not age well. You know what is just as bad as architecture astronauts, wunderkinds ranting about how other smart people are stupid. This whole post feels like the aftermath of some late night argument that probably he should have just deleted in the morning. Not to mention the subtle digs in the pics that he conveniently forgot to caption: is that the MIT campus and two pics from Harvard? If it was revealed that this rant was related to some collegiate affair that only three people in the world remember, I wouldn't be surprised.

That seems off topic. SICP is about understanding language, not architecture. That would be like saying you need to understand how SED and AWK would be implemented is Lisp before you try to write a script to use them together to parse a document.

Come on. Two typos in the first few pages; p.2 "servicees", p.6 "lanuage". I know you are smarter than me, but if seven people decided that an editor would be useless, or spellcheck was unnecessary, then you should be prepared for unwarranted, biased criticisms of your conclusions. You're better than this.

Honestly, what is the purpose of this post? Is HN really the place for clickbait? You would get the same reaction with something like "Do you think functional programming is beneficial for software delivery?" or "Do you think Christopher Alexander was a mediocre architect who just happened to be a mediocre computer scientist?" Please tell me that the person behind this is harvesting the names from this Op-Ed comment thread to build a feedbag for their mech turk. I can't wait to get my exclusive offer for all-natural, water-based, non-toxic lube.

This is a great comment, but I would generalize to just about any other profession. Are nurses bored with bandaids and hoping for better technology? And also comparisons between computer engineering and construction are always problematic because they are at completely different stages of maturity. Maybe what you suggest did happen in 1500 BC when the homeowner was like "Hey buddy, just build this closet with mud bricks" and the carpenter was like "Nar bro, I got these twigs I cut down that are super cool. Mud is for neubs".

I'm old and changes in technology have baffled me for years. So here's a hypothetical: if RSS was still popular, would we be having this conversation? I assume that the next phase in this saga will be a plethora of products suddenly pop into the app store that have some childish implementation of a recommendation algorithm built into what is effectively an RSS reader: add news sites, "like" a link once in a while, and Boom! the recommendation algorithm will filter your subscriptions for "related" articles. Every few months or so, you'll have to dump the algorithm data and "reset" because the implementation is too clunky and ends up building odd combinations. "Why am I seeing only links about Arianna Grande now? Why am I not seeing 'new artist' articles?" And then people will start to bitch about XML and then the whole system will halt and catch fire (again).

I would like to support your comment and add that I enjoy these articles because I like programming languages and thinking about program execution.

However, I think what delibes is getting at is that this is article exhibits a classic trigger for most developers because it starts with naming some language (i.e. Haskell) and then it is filled with assertions that are always "What If": what if your language doesn't support sum types or recursion or algebraic data types or ... Most devs are looking for practical applications for their language of choice so there is a natural inclination toward a critical comparison of "their" language and "my" language.

But we should follow Twisol here and not read this article as "language X is better than language Y" or, more precisely, "throw out unnecessary features from language X because you can still perform some task Z".

Just take the article for what it is: a great "explanation"[1] of the relation between mathematical foundations and language features or characteristics. This article isn't some heretical tantrum so just sit back and enjoy the learning.

[1] https://documentation.divio.com/

This. I've been writing code for years, but every time I pull a repo of the latest web app it turns into a series of frustratingly complicated learning exercises. I'm 17 all over again...

npm? got it. whoop. yarn? okay cool nope. bower, now? wow. all set.. no. webpack. done. wait. gulp? okay okay. are we there yet?

With all due respect, I don't think the question is "how do we simplify SPAs?"; I think the question is "why do we need to run any app in a browser?" Look at the work associated with the "Next Billion Users" project [1]. Most of our assumptions about how-and-why are merely based on luck-and-whim. We didn't arrive at SPAs through some elaborate Grand Design. I just don't understand what a web application offers that cannot be had with a straight client-server application. Are walled gardens and app stores really tyranny when the garden is limited to a certain company/domain? For example, if my bank offers a client-server app that is walled off from the rest of the Internet, should I consider this stifling? If I was working for this bank and developing their client-server app, should I consider this a step back in my career?

[1] https://99percentinvisible.org/episode/the-next-billion-user...

I agree. The semantics even within this set of flowcharts is confusing: blocks start out representing statements but by the time you get to Dependency Injection, they represent anything (library, service, etc.). Also the dotted-line vs solid line doesn't help. With Goto or Exception, the dotted line is the process, not the alternative which is solid. Those need to be inverted because "normal" flow of control from statement to statement is altered and the "exceptional" flow is now active and other statements are ignored. Just waiting for someone to say "we tried this with UML already. please just stop."

I thought that's what solutions like Calcite[1] were for: running queries across disparate data sources. Yes, you still need to have adapters for each source to normalize access semantics. No, not all sources will have the same schema. But if you're trying to combine Postgres and DynamoDB into a single query, you would narrow your view to something that exists in both places, e.g. customer keys, meta data, etc.

Maybe I'm wrong.

[1] https://calcite.apache.org/

I'm not trying to nitpick, but UML is purpose-first, not solution-first. The language always allowed for varying levels of abstraction (i.e. linguistics, not layers), and it was always possible to describe the domain instead of classes+methods, but one is always creating diagrams not code. For example, a collaboration diagram can specify domain concepts and use plain language for activities and artifacts; it is not necessary to consider functions and arguments and exceptions. Oh my.

Your anecdotes are more common with object-oriented languages and poor object-oriented design approaches. Any fool can claim to have discovered a OOD pattern, but a good programmer will not claim to have discovered anything. Instead, she will use the software to express the user's activity and desired outcomes.

That being said, some software languages take more skill and experience to implement a solution than others. Sometimes it is necessary for developers to consider the choice of HashMap over List<?> or worse MyCollection which implements List<?> over an array. These considerations may have created to more types of diagrams (UML, OOD, etc.) that describe software in more an more detail, but what is necessary to express a solution is really subjective and rarely universally understood. You can't sit an inexperienced developer in front of a C++ program and expect them to understand that they are looking at code for a text editor anymore than you could sit them down in front of a collection of DDD diagrams and expect them to build a perfect representation in Java.

We (the royal "We") are looking for a proper balance in design and implementation. That is a work-in-progress: it is the point of this career and won't be captured by single checkbox on one's resume, e.g. "knows UML or not".

This latest article about Detroit developers seems to support that [0]. A meager $300K dished out to politicians opened up the possibility of $700M-$1B plus the developers of these buildings can collect income tax from businesses and folks who occupy them for the next 20 years.

What's the now?!

[0] https://www.metrotimes.com/detroit/how-dan-gilbert-just-scor...

I think your comment is closest to reality. I believe it was incremental and deliberate, but the key piece that is missing from your assessment is that we (the royal "we") haven't given a lot of attention to correcting any poor choices. I think you are right when you say that hardware improvements helped encourage devs to give more tasks to the machine like encoding, caching, etc. However, it also became less important to revisit the underlying pieces on top of which we added these new features. It eventually became this dirty snowball rolling downhill that was built from layers of whatever was in the way as well as anything we could throw at it.

For example, the web might be filled with redundant and bloated software, but the real problem is that the browser has become the nexus of virtualization, isolation, security, etc. for almost everyone from the causal user to hardcore admins and for every piece of software from frameworks/utilities to full-blown SAPs. It's like we have all reached a common understanding for what comprises a "good" application, but then we lazily decided to just implement these things inside another app. I mean, webassembly is great an all, but is it wise?

I don't think it's about IPC or RAM or (n+1) framework layers that each include "efficient list functions". I think it about the incremental, deliberate, and fallacy-laden decisions that assign more value to "new" than to "improved".

I definitely do not understand what's going on here. As noted in the appeal posted by Doctorow [1], DMCA prohibits bypassing DRM so this W3C "approval" seems completely unnecessary. If it's oversight that you want, then a W3C standard isn't the way. A W3C standard is just a description of system behavior; it doesn't carry with it any penalties for deviation. If it did, I would have sued all the browser devs who delayed support HTML5 elements citing compensatory damages: my livelihood was affected!

At the same time, the appeal seems misaligned because (again) the specification may be superior in accessibility, privacy, etc. but the implementation can be total crap. What option do you have? Open a ticket for Chrome or Firefox? Stop watching Fox News because their plugin is buggy and slow?

This whole thing seems like a polite disagreement among intellectuals. The EFF expected more from Berners-Lee but it turns out that he chose to act differently.

[1] https://www.eff.org/deeplinks/2017/07/notice-w3c-effs-appeal...

Flowing Data http://flowingdata.com/ FlowingData explores how statisticians, designers, data scientists, and others use analysis, visualization, and exploration to understand data and ourselves.

I'm not sure I understand this idea. By "read code" do you mean run the program in your head? As in, "start with main(), follow this loop, go to func()..."? Because if that is the case, then I think it is really debugging not reading. It would be great to debug projects and there are many projects that include unit tests which can help guide engineers along a slow path to greater understanding.

Personally, I like writing code and borrowing ideas from other, better engineers. I also like my code to be clean and without cruft: https://github.com/keithb-/Valley

But I don't even know if I could "read" my code. It's a web app; there isn't a main(), there isn't a loop. In order for someone to read it, they would need to mentally "send a request" which means they need to somehow have the concepts or the context in their mind when they sit down with the source code. I just don't know how that is supposed to help an engineer, regardless of age or experience.

I don't use k8s, so forgive my ignorance, but what are the use cases in "the enterprise"? How many "enterprises" need to manage 1K microservice containers to approve weekly timesheets? Is this just a play for companies that want to run their products/services on private cloud?

I think you're asking the right questions.

I would assume that your class targeted Lisp because SICP uses it. While that is a great resource, it is light on details when it comes to the end game: runtime. If you are developing a language today and you aren't considering runtime, then you are just writing macros.

Lexing, and parsing are not trivial tasks, but powerful tooling already exists for these. Compiling means knowing how to translate your language into something that executes, and I would say "must execute well". I'm in favor of hobbies (fun) and exploration (growth), but if you are "perfecting" steps 1&2 and haven't yet considered step 3, then maybe it is time to support another language community rather than develop something on your own.

Thank you for clarifying.

wrt your final decision: obviously, those aren't very compelling reasons. It would be simpler for you to say "We don't care about previous solutions. We're following the standardization track so that people can understand our design and provide comments/suggestions, but we're not going to justify our decision."

For example, the "easily readable" constraint is simply ridiculous because the most common format for data on the web is HTML which survives partly because it can be rendered in a format that is easy to read.

To be fair, I think that previous comment was implying the constellation of XML technologies e.g. XSD, XPath. XML encoding is rarely used in isolation because, honestly, what's the point? Sure, your document is well-formed, but you could achieve the same thing with tab+carriage return.

So if I can continue to clarify the previous comment: given that YANG is an data modeling language, what benefit does it offer when compared with XSD which as been used/tested for many projects?

> XML means "eXtensible Markup Language" - so pretty much exactly a description of the data it contains.

This is the belief that Eric Browne argued against in 2003[1]. "exactly a description of the data" only works when a human looks at it, which is the same argument for JSON. These two things "describe" the same object:

<person><firstname>Eric</firstname></person> { "person" : { "firstname":"Eric" } }

But using Browne's argument, a parser might see these objects as:

<hshhd><uueus>Eric</uueus></hshhd> { "hshhd" : { "uueus":"Eric" } }

How does that description help the parser?

What I'm saying is that XML is system for defining types, subtypes, relationships, etc. and that this type system can be used by programs that are written to interact with document instances in a way that is not dissimilar from other statically-typed languages. In a sense, you're agreeing when you say that XML has been used for programming languages because, in that case, a document instance might contain blocks of programming statements not instructions for a machine. It must be parsed and compiled first which takes some knowledge of the type system, i.e. how to create AST's and transform them into instructions.

I'm also saying that the problem with XML comes from the inability to reason about type systems in a general way. I can give you my XSD but will you know what to do with my data? And if I give you the XSD, and I tell you what to do with the data, then won't we writing the same program? Wouldn't it be easier to just share a library?

[1] http://workflow.healthbase.info/monographs/XML_myths_Browne....

Okay, first of all, the current fascination with JSON is not fundamentally different from the previous fascination with XML. The only thing that anyone can agree on is that JSON is easy to parse just like its predecessor. This is why XSLT came into existence: firstly, it was easy to parse, secondly, ..., thirdly, profit (i.e. reuse, generalization, performance, etc. etc. etc.).

On the other hand, this language is bananas because the programmer is writing the AST and that is what a parser is supposed to do for him/her. Manually coding the AST is like harvesting an acre of corn by hand. If you can find a more inefficient method, then by all means use it.

And just for good measure, XML is not a "data description language", it is a type system; probably the most complex type system I've ever seen and it wasn't a bad idea, it was simply more complex than any application would ever need.

I don't dislike XML, and I think it will continue to live just like Haskell because every generation will come to understand that its extreme faith in generalization has little practical use just about the same time that a new generation first discovers it. So while one is dying to simplify, the other is dying to espouse the existential core of computer science.

>> Can be easily extended by any other developer

This is a tenet that will lead inexperienced developers astray. This "rule" is just too ambiguous. Extensibility is a fascination for object-oriented programmers but in my experience doesn't have a lot of successful examples. Typically I have seen this manifest itself in either a Command+Composite style where every meaningful class is a composite of other SRP classes, or in a proliferation of interfaces that seldom have method definitions and are instead used to enforce coding standards or dependencies.

KISS is incompatible with this rule and you should kill this rule with fire because simple is not extensible. Perhaps when the goal is extensibility then should you consider other developers, but if you are developing a "beige" application then you should not consider extensibility. Instead, just assume that release management will handle changes, i.e. another developer will update rather than extend your class and that will be released in version 1.1.

Of course, to do this also means admitting that version 1.0 of your class was pretty much garbage and that it needed to be "extended". Tough pill to swallow for some.