Hacker Newsnew | past | comments | ask | show | jobs | submit | edocecrous's commentslogin

> he's a great networker who can help his students get good placements

...and bring in $$$.


There's a word for this, and it's the word MIT used: "Professor of the Practice".

You wouldn't a huge portion of the university's faculty to be untrained in research or teaching -- that would be like running a software company where everyone has great ideas but no one knows how to lay down LOCs. But one person here or there who has something significant to bring to the table can be good for the institution.

> but to now have them share that unique and disorganized philosophy with students trying to learn structurally is unfair to the hard work and sacrifice those students have made to be able to get to MIT in the first place.

The author is not directly involved in leading a research group or in teaching. He's a director -- a vision/leadership role. And if he ever were to take up either teaching or advising research, he'd probably receive support and guidance from people who do have Ph.D.'s and have learned the long way around how to research/teach.

Again, that model obviously doesn't work well if you have a huge number of people like this, but one here or there can be a positive thing.


Why regexes combined with the pre-processing?

First, it's not so clear in what sense "efficient" is actually a real requirement if this is a model answer.

If the average input is very small then the cost of compiling/interpreting the regex is going to dominate any modest run-time improvement over even an extremely naive implementation.

And if the inputs are very large then the probability of contradiction in the first few characters even is extremely high, so all the upfront normalization is a huge waste.

I'm having trouble imagining the typical data set where this would be an efficient implementation and where there even exist non-ridiculous inefficient implementations.

Second, doesn't using regexes kind of defeat the whole point of the Palindrome exercise from an evaluation perspective? If someone asked if me if they could use regexes in a coding interview for this question my response would be "good instinct. If you have no other way then go for it. But I was really hoping to see you work through implementing/debugging/commenting/testing an implementation without regexes."


Regexes would not be a good way. Starting a pointer at the beginning and end and moving them toward each other is what I would suggest in an interview. If I was interviewing someone else, I'd also be impressed if they came up with the idea of sorting the string and counting characters (only at most one character could have at odd number of occurrences). Even though sorting and counting is nlogn and requires either storing the sorted string in new memory or else saving the inverse sort to unsort at the end (if the sort is in-place), I wouldn't care. In an interview setting, if they could identify those weaknesses, that's good enough. It's clever and shows attention to detail and good critical thinking for someone to come up with the sort-and-count solution. An interview is not the time nor place to be grilling someone about whether an nlogn solution is really optimal. That's just wasted time.

The fact that the post's author offered regexes as a solution is a bit frightening. In many languages, such as with Python's built-in re module, this is literally impossible, because the regular expression engine is literally confined to check for regular grammars, and you can show that no finite state automaton is adequate for expressing all palindromes (basically because they can't remember an arbitrary number of characters from the start of the string to use at the end).

Of course, lots of languages have regular expression engines that are more powerful than this, but it's a sham for an interview question to rely on that. It doesn't read to me like the post's author actually considered the theory of computation aspect of this, and instead just glibly and naively rattled off that regular expressions should work well.

This is the person judging the candidates on whether they are talented enough at computer science? Yikes.


>I'd also be impressed if they came up with the idea of sorting the string and counting characters

While that method would identify if a string has the necessary attributes of a palindromic string it is not sufficient to prove that a string is a palindrome.

>This is the person judging the candidates on whether they are talented enough at computer science? Yikes.

Right, anyone reading the OP would probably be better served by Steve Yegge's posts[0, 1] on the subject.

[0] https://sites.google.com/site/steveyegge2/five-essential-pho...

[1] http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...

Edit: Went back and actually read the code provided, they only use regex for a preprocessing step.


You're totally right. I was confusing the stated problem with a common associated problem: whether a string is a permutation of a palindrome.


If you use a bucket sort, your time complexity could be O(max(n,k)) and space O(k) where k is the size of the character set and n is the length of the string. Depending on the relationship between n and k, this could be faster than n log n. (But the pointers solution or even comparing against a reversed string seems better for both time and space.)

Also, your solution is poor since it only tells you that a string is _not_ a palindrome in certain cases but cannot tell with certainty that a string is a palindrome. For example, 'aabb' will pass your test but is not a palindrome.


I assume the 'poor' solution you meant was the sort and count solution. You're totally right. I was confusing the stated problem with a common associated problem: whether a string is a permutation of a palindrome.


It's because there is no standard way to determine the properties of a unicode grapheme cluster in JavaScript. Otherwise you could do things like isDigit(), isNumeric(), isPunctuation(), isWhitespace(), etc. Or just ask directly isLetter().

A Grapheme cluster basically corresponds to what a human would consider a "single letter", including any combining marks, etc.


> And if the inputs are very large then the probability of contradiction in the first few characters even is extremely high, so all the upfront normalization is a huge waste.

You're hired! :D


> what is that?

A collection of popular buzz-words in contemporary software engineering research.

> And secondly, does it serve the customer if those are not the customer's requirements?

These are never any customer's requirements. Not a sane customer, at least. Instead, they are (conjectured, probably correctly, to be) generalizations of sufficiently many customers' requirements.

But you're correct -- most customers don't want or need any of those things (except non-linearity. But every piece of software everywhere has this spades.)


I agree they seem like buzz-words, but not from software engineering research. They look entreprisey or startup friendly buzz-words to me.


Or you could read the book. I haven't (summer reading list, again). But it's got a 20-page bibliography, and appendices with all sorts of greek letters that define, well, a lot. I think.

The Black Swan was also by Taleb and probably the most influential finance book of the last 20 years, plus a great read for anybody thinking in 'systems'. It'd give the idea the benefit of the doubt. Sometimes words have no meaning, sometimes it takes some work.


The parent didn't ask what antifragile means. The parent asked what non-linear, proactive, and self adaptive means, especially when taken as requirements for a software system.

Reading Taleb's book to answer that question is probably a lot like trying to extract evolved dogma out of a religious text because each of those words has taken on a life and meaning of their own in SE literature. You can probably eventually get close, but you're better off just reading a few SE papers on those topics and inferring the authors' intended meaning.


A URL to a git repo showing the non-linear, self-adaptive piece of software would be more effective.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: